vtxo: widen onchain spend tracking to onchain-kind vtxos - #1184

rowToVtxo on both SQL backends already carried Kind, but the round-replay
converter (combinedRowToVtxo) and the marker converters built domain.Vtxo
values without it, so a vtxo read through those paths came back as
VtxoKindOffchain regardless of its stored kind. Any guard keyed on Kind
downstream of round replay or marker preload would have been silently wrong.

Note combinedRowToVtxo also drops Depth and MarkerIDs, which predates this
work. Left alone here rather than widening the change, but it means round
replay does not reconstruct the DAG fields either.

An on-chain Arkade UTXO has no batch expiry, so ExpiresAt is not meaningful for
it and is left zero. Without this guard IsExpired would compare against the Unix
epoch and report every on-chain vtxo as expired, which cascades through
RequiresForfeit and the two spend-path checks in service.go and would make them
permanently unspendable.

Behaviour-preserving today: nothing writes VtxoKindOnchain yet, so every
existing row is offchain and evaluates exactly as before.

…vtxo-kind

An on-chain Arkade UTXO joins a batch as a boarding input, signed directly and
never forfeited. IsNote already excludes the kind, which flipped RequiresForfeit
to true for it, so guard it explicitly alongside IsNote and IsExpired.

Same up, down, re-apply sequence on both SQL backends, against a database the
test owns on the shared test server.

…vtxo-kind

…anch

Base for #1181, which needs both #1161 and #1174. The only conflicts
were the generated sqlc files, resolved by regenerating them from the
merged queries and migrations.

Closes #1181. Part of #1159, follow-up to #1174 on top of #1161.

#1174 tracks the onchain spends of unrolled vtxos, the only vtxos with
an onchain output until now. With #1161 arkd also records vtxos held in
on-chain Arkade UTXOs, Kind = Onchain, whose unilateral spends bypass
arkd exactly as an unrolled vtxo's do. Every predicate the tracking
keyed on unrolled now takes either shape:

- Vtxo.HasOnchainOutput is the one Go predicate, unrolled or onchain
  kind, and IsOnchainSpent builds on it.
- The five sql statements, mark, re-point, retract and the two
  candidate selectors, match (unrolled = true OR vtxo_kind = 1) on
  sqlite and postgres.
- The badger selectors take both shapes and its mark guard uses the
  predicate.
- applyOnchainSpends and the restore loop in restoreWatchingVtxos
  follow, the latter through the widened selectors.

SelectSweepableUnrolledVtxos stays as it is: an onchain-kind UTXO has
no checkpoint tx for the sweeper to resolve, and its ark_txid predicate
already keeps onchain spends out.

Tests, on all three backends with Kind = Onchain rows inserted directly
so nothing waits for the write path: mark, re-point and retract work on
an onchain-kind row, the selectors partition by kind as they do by
unrolled, and an onchain-kind row never enters the sweepable set. The
IsOnchainSpent table and the applyOnchainSpends unit test gain the kind
cases. Removing the kind from the predicate fails the domain and
application cases; the sql cases cannot pass on the old statements,
which never matched a row that was not unrolled.

…to pr1184

A test helper named the PR that introduced the on-chain kind, which belongs in
the commit message rather than the source, and it read as though the helper only
made sense against that PR. It now says what the fixture is.

Two comments used a colon where a conjunction reads better.

Comments only.

…tions

The audits that produced the earlier comment cleanups only ever looked at Go
files, so the SQL comments in both backends kept an issue number and two colon
sentences.

Same wording in postgres and sqlite, since the pair should stay readable side by
side.

…' into pr1184

# Conflicts:
#	internal/core/application/onchain_spend.go